Enhancing messages with dynamic content

ABSTRACT

A method for augmenting message streams may comprise receiving a request for augmentation of a message, the request including a parameter associated with the message. The method may further include determining a rule associated with the message. The method may further include applying the determined rule to the message parameters to select an augmentation component. The method may further include transmitting an augmented message to the requestor, the augmented message including the augmentation component.

RELATED APPLICATIONS

The present application is a continuation of and claims priority to U.S.application Ser. No. 17/161,082 filed on Jan. 8, 2021, titled “ENHANCINGMESSAGES WITH DYNAMIC CONTENT,” which is a continuation of and claimspriority to PCT/US2020/052064 filed on Sep. 22, 2020, titled “ENHANCINGMESSAGES WITH DYNAMIC CONTENT,” which in turn claims priority to USSN62/904546 filed Sep. 23, 2019, titled “ENHANCING MESSAGES WITH DYNAMICCONTENT” all of which are hereby incorporated by reference in entiretyfor all purposes.

BACKGROUND

Businesses use text-based communications to communicate with customersfor many purposes. Increasingly, text-based communication is powered bysoftware agents (e.g., chatbots) that map user intent to pre-definedmessage flows. While the message flows can be made arbitrarily complex,in practice the content is predetermined, perhaps augmented withpersonalization information from a Customer Relationship Management(CRM) system or other context.

SUMMARY OF THE INVENTION

As present, chatbot technology is typically predetermined according topredefined message flows. Therefore, it is possible that a userinteracting with the chatbot requests content not able to be provided tothe user, or that opportunities to advertise or otherwise providepromotional content to users are missed. For this reason, there exists adesire to display dynamic promotional content to users. Such dynamicpromotional content is typically not known at the time the message flowis originally defined, can be specific to a particular set of users, andcan be targeted to users based on a particular to time of day,geographic region, or other criteria.

The systems and methods described herein propose a solution to thetechnical shortcomings of present text-based communications by enablingchatbots to perform dynamic (realtime) insertion and/or alteration ofmessaging components in order to allow presentation of promotional,advertising, or user-customized content. The solution presented hereinfurther enables tracking of user interactions with such promotional,advertising, or user-customize content to provide data useful foroptimization of business objectives, such as promotional or advertisingsuccess through click tracking, interaction tracking, and conversiontracking. Such functionality provides businesses with a mechanism toincrease revenue, improve customer retention, and achieve otherimportant objectives.

In one embodiment, a method for augmenting message streams comprisesreceiving a request for augmentation of a message, the request includinga parameter associated with the message; determining a rule associatedwith the message; applying the determined rule to the message parametersto select an augmentation component; and transmitting an augmentedmessage to the requestor, the augmented message including theaugmentation component.

In another embodiment, a system for augmenting message streams comprisesa server configured to receive a request for augmentation of a message,the request including a parameter associated with the message; determinea rule associated with the message; apply the determined rule to themessage parameters to select an augmentation component; and transmit anaugmented message to the requestor, the augmented message including theaugmentation component.

In another embodiment, a method for augmenting message streams isprovided. The method may comprise receiving a request for augmentationof a message, the request including a parameter associated with themessage and an identification of the requestor; obtaining attributesassociated with the requestor identified in the request; combining thereceived requestor attributes with the received request foraugmentation; determining a rule associated with the message; applyingthe determined rule to the message parameters and the received requestorattributes to select an augmentation component; and transmitting anaugmented message to the requestor, the augmented message including theaugmentation component.

In another embodiment, a system for augmenting message streams isprovided. The system may comprise a server configured to: receive arequest for augmentation of a message, the request including a parameterassociated with the message and an identification of the requestor;obtain attributes associated with the requestor identified in therequest; combine the received requestor attributes with the receivedrequest for augmentation; determine a rule associated with the message;apply the determined rule to the message parameters and the receivedrequestor attributes to select an augmentation component; and transmitan augmented message to the requestor, the augmented message includingthe augmentation component.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory and areintended to provide further explanation of the disclosure as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings constitute a part of this specification,illustrate an embodiment of the disclosure, and together with thespecification, explain the methods, systems disclosed herein.

FIG. 1 is a block diagram illustrating a system for augmenting messagestreams, according to an embodiment.

FIG. 2 is a block diagram illustrating a system for amessaging-as-a-product-level (MaaP) chatbot platform for augmentingmessage streams, according to an embodiment.

FIG. 3 is a flow chart illustrating a method for augmenting messagestreams, according to an embodiment.

FIG. 4 is a flow chart illustrating a method for determining whether toaugment a message stream, according to an embodiment.

FIG. 5 is a block diagram illustrating augmentation of a message stream,according to an embodiment.

FIG. 6 is a flow chart illustrating a method for generating a shorteneduniform resource locator (URL) for click-tracking in augmented messagestreams, according to an embodiment.

FIG. 7 is a flow chart illustrating a method for click tracking ofaugmented message streams, according to an embodiment.

FIG. 8 is a flow chart illustrating a method for conversion tracking ofclick-tracked augmented message streams, according to the embodiment ofFIG. 7.

FIG. 9 is a flow chart illustrating a method for interaction tracking ofaugmented message streams, according to an embodiment.

FIG. 10 is an illustrative example of an augmented message stream,according to an embodiment.

FIG. 11 is an illustrative example of an augmented message stream,according to an embodiment.

FIG. 12 is an illustrative example of an augmented message stream,according to an embodiment.

DETAILED DESCRIPTION

Reference will now be made to the embodiments illustrated in thedrawings, and specific language will be used here to describe the same.It will nevertheless be understood that no limitation of the scope ofthe methods/systems is thereby intended. Alterations and furthermodifications of the inventive features illustrated here, and additionalapplications of the principles of the methods/systems described hereinas illustrated here, which would occur to a person skilled in therelevant art and having possession of this disclosure, are to beconsidered within the scope of the methods and systems described herein.

Referring now to FIG. 1, and in brief overview, a block diagramillustrating an embodiment of a system 100 for augmenting chatbotmessage streams is shown. System 100 includes a chat client 122executing on a mobile terminal 124 that communicates with an SMS system114, RCS system 116 or other messaging system 118 via network 112.System 100 also includes an advertisement server 102 that providesadditional content in response to a request from the SMS system 114, RCSsystem 116 or other messaging system 118. Advertisement server 102 mayprovide a hook; functionality created through the implementation of anapplication programming interface (API), or provided as a softwaredevelopment kit (SDK), that connects an existing software chatbot to aweb-based service. The API may be implemented as web services, andprovide for configuration and runtime (e.g., advertisement fetch)capabilities. The SDK may be a publicly documented Software DevelopmentKit to allow easy integration with various programming languages, suchas Python or HTTP. The SDK typically exists as a wrapper over the APIinterfaces, but also provides performance optimizations and additionalfunctionality related to privacy or security. The API may be installedon a processing device such as advertisement server 102, which mayprovide web-based services to the existing chatbot.

Still referring to FIG. 1, and in greater detail, advertisement server102 may include a central processing unit (CPU), or other processingdevice configured to run an operating system on which the API/SDK may beinstalled. Generally, advertisement server 102 is communicativelycoupled to a memory and configured to execute instructions stored in thememory. Such instructions may be altered by the AP/FSDK. Advertisementserver 102 may connect to persistent storage 104. Storage 104 may becloud storage or a physical hard drive configured to store relevantdata, and may be connected to advertisement server 102 directly, by alocal area network (not shown) or by network 112. Storage 104 mayinclude a configuration database 104 a to store matching rules,selection rules, and messaging component templates. Configurationdatabase 104 a may additionally store configuration data for users,moments, and components. Storage 104 may further include a cacheddatabase 104 b, configured to store data used for quick lookups. Storage104 may further include a historical database 104 c, which may beconfigured to hold historical information, which may be used for reportgeneration.

Still referring to FIG. 1, system 100 may also include web console 108that provides role-based access to functionality related toconfiguration database and reporting. Web console 108 provides a webinterface that customers may use to define moments, rules, components,as well as access real-time performance reports. Moments are specificpoints of a chatbot conversion where system 100 can be configured toinsert a component, which may be text, images, and/or actions to displayto the user for a particular moment. A customer may use web console 108to specify components with particular moments, and set rules andfrequency caps to determine how best to enhance the message returned toan end-user interacting with the chatbot.

Still referring to FIG. 1, SMS system 114, RCS system 116 or othermessaging system 118 may fetch, or send a fetch request to advertisementserver 102. A fetch request is a request for dynamic content in responseto the detection of a moment, which is facilitated by the respectiveagent, and often includes a customer or subscriber identifier toidentify the originating chatbot agent, a moment identifier, andtargeting parameters. The targeting parameters may include key-valuepairs used as inputs to rules within the advertisement server 102.Customers may define their own targeting parameters. The informationincluded in the fetch request may be used by advertisement server 102 toapply customer-specific rules to determine content for best enhancingthe chatbot conversation. Such rules may be specifications for how touse the moment and targeting parameters supplied in the fetch request toselect an augmentation component to be returned to the end user.Advertisement server 102 provides an interface that mirrors theinterface used to connect a chatbot agent to a messaging gateway. Thechatbot agent is altered to send messages to the advertisement server102, rather than the messaging gateway. Advertisement server 102 checksthe rules configured in web console 108 in realtime against the messagetraffic, and takes action as necessary. The rules may be used todetermine which components to insert as a payload into a chabot messagein response to the fetch request.

Still referring to FIG. 1, system 100 may further include a reportserver 110 that collects information generated by other systemcomponents, such as fetch requests, click events, and conversions, andintelligently processes it such that it can be used to understand andoptimize business objectives via realtime and/or summary (batch)reports. Report server 110 may be further configured to deliver thereports via various transports (email, text message, cloud storage, ftp,via web console 108), to provide additional diagnostics information tocustomers.

In some embodiments, whenever a fetch request is received for which nocomponent matches, advertisement server 102 records information aboutwhy various rules and components in the system were disqualified forconsideration, and stores such information in historical database 104 c,which is then made available to report server 110. This information isvaluable in troubleshooting rule configurations, and may be recorded byinstrumenting the fetch process, so that whenever a rule or component isfiltered out from consideration (which normally happens because atargeting rule was not matched, or some frequency cap or other limit hasbeen exceeded), a message is appended to an internal collection of theform: “Rule X was disqualified because it requires someParam=someValue,but “someParam” was not specified in the fetch request.” All suchmessages are provided in the fetch response, and are stored inhistorical database 104 c. Such messages may be made available to thecustomer by advertisement server 102 via web console 108 or via a reportgenerated by report server 110. This saves considerable time in managingthe system because it allows the customer using web console 108 or whoconfigures report server 110 to detect problems such as misspellings oftargeting parameters, or incorrect assumptions about the possible valuesparameters encountered at runtime.

Network 112 may be a wireless or a wired connection, and may furtherserve to connect advertisement server 102 to an SMS system 114, RCSsystem 116, or other system 118 configured to host chatbot agents. SMSsystem 114 may host an SMS agent, a customer-specific softwareapplication that integrates with SMS gateways. RCS system 116 may hostan RBM agent, a customer-specific software application that integrateswith Messaging as a Product (MaaP) gateways. The gateways are webservices providing bidirectional communication services allowing acompany to communicate with a subscriber over a particular channel, suchas SMS, RCS, or the like, and are often provided by a third party. Othersystem 118 may host another type of chatbot agent on the other chatserver that may be compatible with the APIs of advertisement server 102.Such agents are existing platform-specific services typically owned bythe customer. An agent is primarily responsible for managing the flow ofmessages between a subscriber (user) and a company, and may be builtatop a commercial provider or may be a custom implementation. In orderto differentiate between the chatbot agents of different customers,advertisement server 102 may differentiate between networks, which arecollections of moments, rules, components, and associated user accountslogically connected with a single customer property. A user account maybe associated with more than one network if, for example, the customermanages multiple independent messaging channels.

In some embodiments, network 112 may also connect advertisement server102 to an external customer relation management database 120 that istypically used to store targeting parameters. Targeting parameters caneither be passed to advertisement server 102 as part of an API request,or can be queried by advertisement server 102 during the fetchprocessing if access to CRM database 120 has been configured. Additionaltargeting parameters may be retrieved from CRM database 120 in the eventonly a partial fetch request has been generated, as will be describedwith reference to FIG. 4.

In many cases, a chatbot is accessed by a mobile terminal 124 via a chatclient 122. The chat client may be capable of connecting mobile terminal124 to network 112, and thus to a chatbot agent hosted by chat client122. When displaying the messages to the end user, chat client 122 mayallow any chabot agent currently connected to mobile terminal 124 todisplay the augmented content in the chatbot message exchange.

Advertisement server 102 may utilize a fetch service that determineswhether a message should be inserted or altered, selects an appropriatealteration or insertion based on user-defined rules, and performs amanipulation of the original message to insert/modify it. Advertisementserver 102 may also be programmed to provide an interaction-trackingservice that detects and tracks interactions that chatbot users havewith messaging components delivered by the system, including conversionevents that may occur in a secondary medium, such as a website orinteractive voice response (IVR) system.

In a typical integration of system 100, a customer will use the API orSDK compatible with their software environment to connect their chatbotagent to advertisement server 102. In this configuration, the chatbotagent communicates directly with advertisement server 102, perhaps viathe SDK. This requires that the chatbot agent have all of theinformation necessary to generate a full fetch request, including all ofthe targeting parameters specific to the current subscriber. It alsorequires that the chatbot agent be able to handle service interruptionsthat could affect the fetch process, such as the temporaryunavailability of an internal system that provides subscriber targetinginformation.

To deal with these types of situations, some embodiments of system 100may include an optional request proxy 106. The request proxy 106implements a chatbot agent-facing interface that looks and acts almostidentically to the advertisement server 102 fetch service APIs, butprovides the ability to be configured such that it can connect tocustomer-specific (internal) CRM systems. In addition, request proxy 106can provide support for robust handling of temporary serviceunavailability and custom URL shortening.

Request proxy 106 allows chatbot agent requests to be augmented withadditional information or capability before being processed byadvertisement server 102. Request proxy 106 can, for example,communicate with customer-specific CRM 120 in order to provideadditional targeting parameters at runtime, and it can provideredundancy and fault tolerance if external services are temporarilyunavailable.

Request proxy 106 includes two distinct parts, a common part configuredto handle functionality required by every customer, and acustomer-specific plugin that handles custom interfaces withcustomer-specific systems. The customer-specific plugins can beimplemented as webhooks provided by the customer. A typicalimplementation uses request proxy 106 to interface between advertisementserver 102 running in the cloud and the customer's CRM systems, whichmay be running in a protected environment. For example, request proxy106 could be configured with Internet Protocol (IP) whitelisting andauthentication information that is specific to a customer, and providedas part of the customer's configuration. The connection between thewebhook and the customer's CRM systems is controlled by the customer, sothe customer can implement any additional/different security mechanismsthey require.

In some embodiments, in addition to the customer-specific webhooks,request proxy 106 may maintain a local database that is capable ofstoring subscriber-specific targeting parameters. For example, if acustomer wanted to segment their subscriber population into a number ofcohorts for the purposes of a particular ad campaign, request proxy 106may allow the customer to upload a CSV containing a mapping ofsubscriber identifiers to cohort identifiers, and assign those mappingsto a particular targeting name (e.g., “cohort”). Request proxy 106 usesinformation from its local database to further augment the targetinginformation.

System 100 provides a multi-tenant web application, which means thatmultiple customers' data may be loaded into the same instance of thevarious databases used by the system. To keep each customer's dataseparate from each other's, all data records may have a field named“network”, which uniquely identifies a particular customer network. Thesystem has a data access layer between the databases and the programlogic. This data access layer ensures that requests for data from thedatabases are only provided access to records with the appropriatenetwork. For example, when a customer signs into web console 108, webconsole 108 authenticates the customer before allowing any requests ofthe API on advertisement server 102. The API uses the authenticatedcustomer identification to provide the data access layer with theappropriate network for the customer. The data access layer will onlyprocess records that match the given (authenticated) network.

For simplicity, the rest of this document will omit the “network”property from the definitions of data records. It should be assumed thatthis property is always present in the database.

While described as having an advertisement server 102, it should beunderstood that the components of system 100 are capable of dealing withany type of messaging component on behalf of a customer. Customers usesystem 100 not just to serve revenue-generating advertisements, but alsoto insert customized messaging into chat-based communications that servepurposes other than direct revenue generation.

That said, for convenience we will use the language of advertisementserving to describe the functionality of system 100.

A customer provisions access to the functionality of system 100 bycreating one or more accounts using the public-facing web console 108.Multiple user accounts may be associated with a particular network, andthose user accounts may be either read-only or read-write. Once anaccount has been provisioned, one or more API Keys can be obtained fromweb console 108. API Keys are specified in API calls (or indirectly, viathe SDK) and identify the customer's network in interactions withservices of system 100. The customer uses web console 108 to specifymoments, rules, and components (described below) that comprise theconfiguration data for the customer-specific network that togetherdetermine what messages will be delivered to customers in whatsituations.

With an account provisioned and an API Key, the customer adds one ormore hooks to their chatbot agent. Hooks are typically created byinserting a call to the appropriate fetch routine provided by the SDKinto the software powering the chatbot. When using a commercial chatbotplatform, hooks may be provided using a platform-specific manner, suchas by adding a label to a particular point in a dialog flow chart.

Hooks are used by the chatbot agent as a way to notify advertisementserver 102 that some particular point in a customer conversation hasbeen reached, and to allow advertisement server 102 to determine basedon the current configuration and runtime context, whether any configuredcontent (e.g., components) should be delivered to the customer. Thisprocess is known as a fetch (or fetch request) and is the core functionof system 100. When handling a fetch request, advertisement server 102looks at the specific moment and targeting parameters specified by thefetch request, compares them with the rules that have been configured bythe customer and with historical information recorded about previousinteractions in historical database 104 c to determine if there is acomponent that would be appropriate to deliver to the customer.

The typical embodiment is for the hook to be integrated directly into acustomer's chatbot agent by way of the SDK for the customer platform.The SDK can integrate directly with the gateway interfaces provided bySMS system 114, RCS system 116, or other system 118 and performclient-side functionality that improves performance.

If the SDK cannot be used, for example if the chatbot agent is writtenin an unsupported programming environment or using a third-partyplatform, the integration may make direct use of the APIs, which provideessentially the same functionality as the SDK but with more effortrequired on the part of the customer. It is also possible to integratethe hook in the gateway itself of a system via a custom integration ofthe gateway. This has the benefit of being able to enable thefunctionality of system 100 for a large number of chatbots withouthaving to make any customer-specific changes. For example, the gatewaycould provide the functionality of system 100 to its customers allowingthem to insert ads or other messages into conversations.

Finally, the hook can be configured such that it mimics the interfaceprovided by the gateway, essentially acting as a man-in-the-middlebetween the chatbot agent and the gateway. This has the benefit of notrequiring any changes to the chatbot agent or gateway other than minorconfiguration changes, such as changing the URL used by the chatbotagent to communicate with the gateway through the API/SDK.

If it finds an appropriate component, advertisement server 102 performsany dynamic processing appropriate (for example, a component may use atemplated string, into which a customer's name should be inserted atruntime), and converts it from an internal data format into a formatspecific to the gateway being used by the chatbot agent, and returns itto the chatbot agent. The chatbot agent uses the services of the gatewayto deliver the message to the customer.

When the customer interacts with the message, for example by followinglinks in a message or otherwise interacting with a message, theseinteractions are tracked by advertisement server 102. Interactiontracking is often done by re-writing customer-supplied URLs to redirectthrough advertisement server 102, but in some cases may involve the SDKinteracting with the gateway. For example, when an RCS message isdelivered to a subscriber, the RCS gateway may notify the customer agentwhen the subscriber has read the message. This “read receipt”notification may be intercepted by the SDK running on the agent, andinformation about the event is forwarded to advertisement server 102using the API.

When a subscriber follows a link from a message provided byadvertisement server 102, it is generally redirected through aninteraction-tracking service. This allows the click event to be tracked,and also provides an opportunity to provide the subscriber's user-agentwith an HTTP conversion-tracking cookie. If the customer has a websiteon which product purchases or other goals may be fulfilled bysubscribers, the customer can use the API Key provided earlier to put atracking pixel or snippet of Javascript on the goal website that directsthe subscriber's user-agent to make a web request to advertisementserver 102. This allows advertisement server 102 to inspect the cookieson the user agent, and record a conversion associated with thesubscriber if appropriate.

Every interaction between the chatbot agent and advertisement server102, such as fetch requests, and interactions between subscribers andcomponents, for example clicks and conversions, are recorded inhistorical database 104 c, enabling advertisement server 102 to groupthe various events in such a manner that it can determine, for example,the relative click-through and conversion rates for different componentsusing the same rule. Information such as this can be displayed by webconsole 108 so that the customer can view reports showing the volume andperformance of their network, and optimize future delivery.

FIG. 2 is a block diagram illustrating an integration embodiment 200 ofsystem 100 providing messaging-as-a-product-level (MaaP) chatbotplatform for augmenting message streams, according to an embodiment.Text-based communications between a human and a chatbot often relies onmultiple “back-and-forth” messages to accomplish a task. When adding apromotion or advertisement, it is desirable that the user can interactwith the promotion in a similar way. For example, the user should beable to have a “side conversation” with the promotional content. Such aside-conversation would not normally be possible with astatically-defined intent-based conversation agent, because theinformation necessary to maintain state about the conversation must beknown ahead of time.

Embodiment 200 allows for dynamically-inserted messaging components tohave multiple interactions between the messaging component and a humanuser without modifying the underlying message script. This is done byessentially “pausing” the statically-defined conversation when a userinteracts with a dynamically-inserted messaging component, and onlyresuming the original conversation when a specific event occurs. Inorder to pause the original conversation, the code that mimics themessaging gateway interface temporarily re-routes the message trafficthat would normally flow between the human and the software agent suchthat it flows from the human to a software agent defined and controlledby a system such as system 100 of FIG. 1. For example, in embodiment200, a chatbot platform 206 interfaces with a plurality of MaaP gateways204. During a particular chatbot instance 208 with an end-user, chatbotplatform 206 may receive a request to augment the content in chatbotinstance 208. While the current conversation of chatbot instance 208 maybe handled by MaaP gateway 204 a, the chatbot platform 206 may reroutethe request to a second MaaP gateway, such as MaaP gateway 204 b suchthat the request can be handled without needing to pause the presentinteraction. This mechanism allows, for example, one company to“transfer” a conversation to a different software agent, potentiallyimplemented by a completely different company, such as switching fromcarrir 202 a to carrier 202 b, without the user being required to changecontexts.

In practice, many useful tasks can be accomplished with a scheme thatallows for only a single additional back-and-forth message transactionbetween the user and the smart messaging component. For example, apromotion for a company service may be tapped on by a user. In response,a new messaging component could be presented that asks the user to entertheir zip code, email, phone number, or some other type of information.The smart messaging component can collect this information, write aconfirmation message, and then return the user to the original state ofthe conversation that occurred before they interacted with the smartmessaging component.

FIG. 3 is a flow chart illustrating a method 300 for augmenting messagestreams in response to a fetch request, according to an embodiment. Afetch is the process used by the chatbot agent to request dynamiccontent from the advertisement server. FIG. 3 shows the sequence ofsteps used by the fetch service to fulfill a fetch request, whichinvolves collecting (1) information from the fetch request, (2)configuration information from the configuration database, and (3)cached data from the cache in order to determine the appropriate bestresponse, if any, for the fetch request. Method 300 may be implementedby a system such system 100 described with reference to FIG. 1, withparticular reference to advertisement server 102. At the end of thefetch request, the fetch service will return either a fully-formattedmessage payload suitable for delivery to the chatbot agent's gateway(based on the format parameter provided in the fetch request), or anindication that no component was suitable for delivery. All of theparameters from the fetch request, as well as information about thereturned message (if any), are stored in a historical database, suchhistorical database 104 c described with reference to FIG. 1, for futureprocessing. Method 300 is a highly performance-sensitive operation andnumerous optimizations have been made to ensure that it responds to thecaller extremely quickly. For example, the recording of information inthe historical database is deferred until after the HTTP response hasbeen sent to the requestor, and subscriber-specific informationnecessary for the fetch processing is stored in a specialized in-memorydatastore.

Method 300 may begin with a step 302, in which an advertisement server,such advertisement server 102, may receive a fetch request. The fetchrequest may be generated by a chatbot agent in response to detection ofa moment. Moments may be configured by the customer using a web console,such as web console 108 described with reference to FIG. 1, or via anequivalent API interface. They are comparable to advertisement units inweb-based advertisement serving technologies, consisting of simply aunique code that is bound to a human-readable name and/or descriptionusing the web console. The basic structure of a moment includes codesuch as a string identifier used to identify the momentprogrammatically, for example, an identifier passed by the chatbot agentas part of the fetch request. The moment may also include ahuman-readable name and description for display in the web console uponreceipt of the fetch request at the advertisement server, which isconnected to the web console.

The fetch request received at step 302 will now be described withreference to Table 1 below. Each fetch request includes differenttargeting parameters that serve as moment identifiers, a subscriberidentifier identifying the subscriber operating the chatbot agent whichgenerated the fetch request, and a format identifying the type ofcommunication and thus the type of gateway for which any responsemessage must be formatted.

TABLE 1 Fetch Request Format Moment moment-identifier Targetingkey1-value1 key2-value2 . . . keyN-valueN Subscribersubscriber-identifier Format [“SMS”, “RBMv1”, “FBM”, . . . ]

In some embodiments of step 302, the chatbot agent will be configuredsuch that it will specify a moment by code when calling theadvertisement server's SDK fetch method (which itself sends the actualfetch request to the advertisement server). The fetch request mayrequire that the moment code be specified, or the SDK may includespecial functionality enabling the chatbot agent to be written in such away that it need not be aware of which moments have been defined at all.Instead, the moment may be auto detected by the SDK, and the SDK canspecify the appropriate moment code for a fetch request. The ability toautomatically detect moments may be achieved by using regularexpressions (RegEx). For example, a customer may have defined a momentnamed “ORDER_COMPLETE”, which is used in the web console to define a setof rules and components that should be invoked when a subscriber hasplaced an order. Using the moment detection by Regex feature, thecustomer uses the web console to define a mapping from a regularexpression to a moment, which may be stored in the database. Forexample, the regular expression “/order is complete/” might be mapped tothe ORDER_COMPLETE moment. The SDK may obtain a table of regularexpression mappings at initialization, which may be updated duringruntime. An example of the use of Regex is outlined below in Table 2.

TABLE 2 Regex Moment Mapping Regular Expression Moment ID /order iscomplete\./ ORDER_COMPLETE /welcome back/ WELCOME /visit us/ CONTACT

When the chatbot agent delivers a message to the subscriber, they alsopass the text of that message to a conditional fetch method supported bythe SDK, running locally on the chatbot agent. The agent may inspect themessage, and compare the text portion of the message with its configuredregular expressions. If it finds a match, the chatbot agent may beprogrammed to generate a fetch request to send to the advertisementserver, specifying the moment that was specified in the rule. Suchfunctionality prevents additional round trips to the advertisementserver if no match is found, prevents transfer of potentially sensitiveinformation over the network, and does not require updates to thechatbot agent configuration when new moments are added via the webconsole.

Method 300 may continue with a step 304, in which the advertisementserver retrieves the moment from the fetch request received by parsingthe content of the request. Step 304 may be followed by a step 306, inwhich the advertisement server retrieves recent events from a database,such as historical database 104 c described with reference to FIG. 1.During step 306, the advertisement server gathers the informationnecessary to proceed to step 308, in which the advertisement serverdetermines whether a moment frequency has exceeded a particular capacity(e.g., the number of moments of a particular moment identifier hasexceeded a maximum in the specific chatbot instance executing method300).

During step 308, the advertisement server uses the data obtained fromthe historical database to determine if a user-specific frequencycapacity has been reached for the named entity for the identifiedmoment. Frequency capacities may be applied to various entities,including ad units, line items, and creatives. Frequency capacities mayalso be applied to labels or collections. The format of frequency capsmay be common to all entities, such as in the following example of anentity-embedded simple ‘frequency’ object:

  { times: number// serve this entity at most ′times′ times... interval:number,  // in every ′interval′ milliseconds }

Every subscriber has an associated database entry called a subscriberhash that contains one key for each entity that they have been served.The value of each key is the timestamp of the time it was last served tothem. An example of a frequency capacity limit used to determine yes orno in step 308 is as follows:

function isLimitReached(  subscriberHash: { [key: string]: string },key: string,  frequency: { interval: number }, ) {  if (!frequency ∥!frequency.interval) {   return false;  }  const lastSendString =subscriberHash[key];  let lastSend: number;  if (lastSendString != null){   lastSend = parseInt(lastSendString, 10);   if (isNaN(lastSend)) {   lastSend = null;   }  } return lastSend && lastSend +frequency.interval > getCurrentTime( ); } export functionisAdUnitLimitReached(  subscriberHash: { [key: string]: string }, adUnit: IAdUnit, ): boolean {  return isLimitReached (  subscriberHash,   adUnit._id.toString( ),   adUnit.frequency,  ); }export function isLineItemLimitReached  (subscriberHash: { [key:string]: string },  lineItem: ILineItem, ): boolean {  returnisLimitReached   ( subscriberHash,   lineItem._id.toString( ),  lineItem.frequency,  ); } export function isCreativeLimitReached (subscriberHash: { [key: string]: string },  creative: ICreative, ):boolean {  return isLimitReached(   subscriberHash,  creative._id.toString( ),   creative, frequency,  ); }

If the advertisement server determines in step 308 that a frequencycapacity has been exceeded, method 300 may continue to a step 310, whichincludes returning a “no content” response by the advertisement serverto the chatbot agent. If no such frequency capacity has been exceeded,the advertisement server determines no in step 308, and proceeds to astep 312.

Step 312 may include the advertisement server retrieving rulesassociated with the moment from a database, such as configurationdatabase 104 a described with reference to FIG. 1. The advertisementserver may include a decision engine as part of the fetch service, whichresponds to a fetch request specifying a given moment depending upon thecurrent customer configuration. In particular, rules are used to dictatewhich components, if any, are eligible to be returned for a givenmoments. If no eligible rules exist for a given moment, then a fetchrequest that specifies that moment will not respond with any content.

The rules specified in the configuration database provide theinformation necessary for the advertisement server to determine whichcomponents are eligible to be served for a given fetch request. Eachrule consists of a set of targeting conditions, limits, and components.The targeting conditions are used to compare targeting parameterssupplied by a fetch request. Only if all of the targeting conditionsevaluate to true does a rule match a fetch request. When a rule matchesa fetch request, each of the components associated with the rule is putinto the eligible pool to be returned to the requestor; as such, whenthe advertisement server determines a particular rule does not match,the associated component is removed from the eligible pool. Thelimit-based rules allow the customer to specify things like a maximumnumber of times that the rule may match in a day, or the maximum numberof clicks that a rule should be associated with before it is disabled.Method 300 may apply the rules in a step 314, in which the advertisementserver filters rules by limits; a step 316, in which the advertisementserver filters rules by targeting parameters; and a step 318, in whichthe advertisement server filters rules base on subscriber frequencycapacity.

Step 314 may include the advertisement server filtering the rules basedon limits set by the customer via the web console. Such limits mayinclude limiting the rules based on a max number of impressions or anumber of impressions per day reached by the chatbot agent or specificchatbot instance. During step 314, advertisement sever may determinethat certain rules do not apply based on the limits established by thecustomer for the moment specified in the fetch request.

Step 316 may include the advertisement server filtering the rules basedon the targeting parameters included in the fetch request. Suchtargeting parameters may include specific keys for which certainconditions must be met. The conditions may include equal to, is greaterthan, is less than, is not, is one of, or the like and a qualifyingvalue to which to compare the key. Such targeting parameters may bespecified by the end-user during the chatbot conversation, or may beautomatically applied by the chatbot agent or advertisement server basedon the moment. During step 316, advertisement sever may determine thatcertain rules do not apply based on the moment not meeting theconditions established by the rules. An example of code directed tofiltering rules by targeting parameters is as follows:

  export function ruleTargetingFilter  ( rule_criteria,  targeting, ):boolean {  if (!rule.criteria) {   return true;  }  for (const criterionof rule_criteria) {   const key = criterion.key;   const value =criterion.value;   const comparator = criterion.comparator;   if(comparator === ″is″) {    if (!(key in targeting ∥ targeting[key] !=value) {     return false;    }   } else if (comparator = = = ″is not″){    if (key in targeting && targeting [key] == value) {     returnfalse;    }   } else if (comparator = = = ″is less than″) {    if (!(keyin targeting) ∥ targeting[key] >= value) {     return false;    }   }else if (comparator === ″is greater than″) {    if (!(key in targeting)∥ targeting[key] <= value) {     return false;    }   } else if(comparator === ″is one of″) {    const values = value.split(″,″);    if(     !(key in targeting) ∥     !values.some(v => targeting[key] == v)   ) {     return false;    }   }  }  return true; }

Step 318 may include filtering rules according to a subscriber frequencycapacity. In such a step, the advertisement server may determine fromhistorical data that a particular subscriber has exceeded a number offetch requests, which may be a subscriber (e.g., an end user) onlyhaving a certain number of fetch requests able to be fulfilled in aparticular period of time. If such a rule applies, the advertisementserver will remove any components from the eligible pool for which suchfrequency capacity limits may apply. Step 318 may be followed with astep 320, in which the advertisement server determines whether there areany rules remaining. If the advertisement server determines no, method300 returns to step 310, and returns an error, because no components orcontent match the moment specific in the fetch request. If, during step320, the advertisement server determines yes, method 300 may continue toa step 322.

Step 322 may include the advertisement server retrieving any componentsassociated with the remaining rules from the configuration database. Aspreviously described, any rules for which the moment is a match may havean associated component. As such, if any rules match the moment, aneligible pool of components is identified by the advertisement serverfor potential insertion into a fetch request response for augmentationof a chatbot message.

Components are specified by the customer using the web console or via anequivalent API interface. There are two primary types of components usedfor smart messaging: text components, and card components. A typicaltext component will consist of text payload and an optional action. Atypical card component consists of one or more text strings, optionalmedia such as an image or video, and one or more actions. Actions thatare associated with components may be simple web hyperlinks,click-to-call buttons, or may open maps or other associated applicationson a subscriber's device. Not all gateways support all action types, so,for example, a component intended for SMS delivery may only supportsimple web (HTTP) links as actions. Components may also be defined withone or more customer-specified properties. These properties are notinterpreted by the advertisement server, but instead are provided to thechatbot agent as part of the fetch response. They allow the chatbotagent to track custom data associated with a component, such as a stockkeeping unit (SKU) number or other internal information. Example code ofa component and an associated action is as follows:

  export interface ICreative extends Document  { name: string; description?: string;  format: string;  payload?: {   text?: {    text:string;   };   card?: {    url: string; title: string;    description:string;    cardOrientation: string;    thumbnailImageAlignment: string;   mediaHeight: string;   };  };  actions?: [IAction];  properties?:[IProperty];  frequency?: {   times: number;   interval: number;  }; network: INetwork; } Action Definition  export interface Iaction  {actionType: string;  text: string;  action: string; }  export interfaceIproperty  { name: string;  value: string; }

Similar to step 318 of method 300, the advertisement server may performa step 324 in which the eligible pool of components is filteredaccording to a component frequency capacity, which may be limited basedon a type of subscription provided by a customer operating the chatbotagent to which a subscriber has subscribed. After filtering thecomponents in step 324, method 300 may continue to a step 326, in whichthe advertisement server determines whether, after filtering, anyeligible components remain. If the advertisement server determines noeligible components remain for augmentation of the message (no in step326), method 300 proceeds to step 310, in which the advertisement serverreturns a “no content” response to the chatbot agent. If theadvertisement server determines that eligible components remain (yes instep 326), method 300 continues to a step 328.

In step 328, the advertisement server selects any remaining componentsfor insertion into the chatbot message as a payload of the message. Theformat of components is independent of any particular messagingtechnology or vendor-specific Gateway. When method 300 determines acomponent to return to the caller, it first renders (or converts) thecomponent into a format that is understood by (or defined by) thegateway used by the requesting chatbot agent. The format into which thecomponent is converted is specified using the format field of the fetchrequest. Multiple formats are supported, and a pluggable architectureallows new formats to be supported.

Method 300 may proceed to a step 330, in which the advertisement servergenerates a payload field of the fetch response message, in which therendered component is returned as a simple string object. This objectneed not be interpreted in any fashion by the chatbot agent, rather itcan simply pass the object unaltered to the appropriate interfacesupplied by their Gateway. This has the advantage of insulating theAgent from any changes to message formatting. Step 330 may generate thepayload and format the fetch response according to the fields specifiedin Table 3.

TABLE 3 Fetch Response Format Message-id Unique identifier that can becorrelated with the fetch request Payload Message payload, suitable forpassing directly to Gateway Format Specifies the format of the payload,e.g., SMS, RBMv1, FBM Media Collection of urls to media files that areincluded in the Payload

Method 300 may continue with a step 332, in which the advertisementserver sends the fetch response to the chatbot agent including thepayload. In some embodiments, the advertisement server may utilize afetch proxy, such as request proxy 106 described with reference to FIG.1, to send the fetch response to the agent specified in the message-idproperty of the fetch response. Step 332 may include receiving aconfirmation from the chatbot agent or host server of the agent that thefetch response was received properly.

In some embodiments, some Gateways that require a multi-step process ofdelivering messages to subscribers that contain embedded or linked mediafiles. For example, a known gateway requires that before a messagecontaining media files like images or videos can be delivered to asubscriber, those media files must have been previously uploaded totheir servers using a proprietary interface. In order to simplifychatbot agent integrations, the SDK inspects the media property of allfetch responses received from the advertisement server, andautomatically begins a process of uploading the necessary media files tothe gateway. Once all of the media files have been uploaded, the payloadis modified in order to fix up references to the media files (the filestypically have a new URL assigned to the tem by the gateway uponupload), and the modified payload is then sent to the gateway.

After sending the fetch response with the payload, the advertisementserver executing method 300 may proceed to a step 334 in which theadvertisement server may update the database with the payloadinformation. Step 334 takes place after step 332 to minimize processingtime for the advertisement to respond to the fetch request. Theadvertisement server may update the historical database with the payloadinformation by creating a database record including the informationincluded in the original fetch request and the payload transmitted withthe fetch response. By recording the payload and associated fetchrequest in the database, the advertisement server ensures that thesubscriber records are updated upon the next execution of method 300,such that the limit or frequency capacity rules are applied to the nextmoment correctly. Method 300 may terminate with step 334, and may repeatupon receipt of another fetch request by the advertisement server.

FIG. 4 is a flow chart illustrating an example of a method 400 ofaugmenting a fetch request using a fetch proxy according to anembodiment. Method 400 is particularly useful in instances where achatbot agent associated with a customer may not have access tocustomer-specific information stored in a customer relation management(CRM) database that is useful for targeting parameters. For example, acustomer may utilize a third party to implement a chatbot agent, and thethird party may not have access to the customer-specific information, orsuch an agent may be hosted in an insecure environment where customersecurity policy prevents agent access to an internal CRM system.Additionally, some software environments running the chatbot agent maynot be suited to handling temporary service unavailabilities, orunresponsive external hosts. For example, some software environments donot allow for automated retries, or queuing of failed requests for laterprocessing. Method 400 utilizing the fetch proxy can alleviate suchshortcomings. For example, a primary use of method 400 includesaugmenting a fetch request with targeting parameters that areunavailable to the chatbot agent at runtime through use of the fetchproxy.

Method 400 may be implemented by a system such as system 100 describedwith reference to FIG. 1. In particular, the fetch proxy may operatesimilar to request proxy 106. The fetch proxy may be configured toreceive a partial fetch request from the chatbot agent and determinewhether or not to augment the fetch request with additional parametersobtained from a customer-specific database at runtime, such as externalcustomer relation management database 120. The fetch proxy acts as aninterface between chatbot agents and an advertisement server (such asadvertisement server 102 of FIG. 1), and may be hosted in the cloud.

Method 400 may begin with a step 402, which includes the fetch proxyreceiving a fetch request, fetch request may have been generated by theagent or by a server operating the agent, and includes subscriberidentifier uniquely identifying the subscriber for whom the request isbeing made.

Method 400 may continue with a step 404, which includes the fetch proxydetermining whether to augment the fetch request. Such a determinationmay be made by determining whether the fetch request is a partial fetchrequest, which is a valid fetch request, but omits some/all of targetingparameters used to determine which content to augment to the chatbotconversation, if any. If the fetch proxy determines that the fetchrequest is complete, method 400 may continue to a step 406.Alternatively, if the fetch proxy determines the that the fetch requestis indeed a partial fetch request, method 400 may continue to a step408.

Step 406 may include the fetch proxy initiating the fetch request withany existing targeting parameters included in the complete fetchrequest. Method 400 may end with step 406, and may repeat upon the fetchproxy receiving another fetch request.

Step 408 may include the fetch proxy requesting additional parametersfrom a data source. The data source may be a customer CRM system. Thefetch proxy may make use of a secured interface to collect additionaltargeting parameters specific to the subscriber and situation based onthe subscriber identifier. The interface between the fetch proxy and thecustomer-specific CRM providing the targeting parameters can be definedto use standard secure internet proxies. Such an interface may be asubscriber lookup webhook. This interface allows the fetch proxy to takean opaque subscriber identifier (which is provided in the fetch requestfrom the agent) and pass it to the customer's configured webhook toretrieve a collection of name-value pairs representing targetinginformation for that subscriber from the customer CRM database, usingthe subscriber identifier as a key. Step 408 may include the fetch proxymaking a call to the customer's CRM system using the configured“subscriber lookup” webhook, via an authenticated proxy. Multiplewebhooks are allowed to be configured for a given customer, such thattargeting information can be obtained from multiple sources throughoutan organization, thereby enabling larger organizations having multipledatabases storing information relevant for targeting to use method 400.

Method 400 may continue with a step 410, which includes the fetch proxydetermining whether data (e.g., the requested additional parameters) isto be returned from the customer's CRM database. Step 410 may includethe fetch proxy communicating via the customer's webhook with theinternal CRM system to lookup name-value attributes (additionalparameters) associated with the given subscriber identifier, anddetermining if any attributes exist in the database to be returned tothe fetch proxy. If no attributes exist, method 400 may continue to step406, and end. If step 410 returns additional parameters in the form ofname-value attributes, method 400 may proceed to a step 412.

Step 412 may include merging the additional targeting parametersreturned in step 410 with the existing targeting parameter included inthe partial fetch request. In step 412, the fetch proxy combines thename-value targeting values obtained from the CRM (via the configuredwebhook) with any targeting values that had been provided in theoriginal fetch request, thereby completing the partial fetch request.

Method 400 may continue with a step 414, which includes initiating thefetch request with the merged targeting parameters by the fetch proxy.In step 414, the fetch proxy forwards the augmented fetch request (i.e.,the request with potentially additional targeting parameters) to theadvertisement server for processing. Method 400 may end with step 414,and may repeat at a time when the fetch proxy receives a new fetchrequest.

FIG. 5 illustrates a diagram 500 depicting augmentation of a messagestream, according to an embodiment. Diagram 500 includes an originalrich communication service (RCS) message 502 which includes a momentdetected by a fetch proxy or advertisement server, such as request proxy106 and advertisement server 102 described with reference to FIG. 1.Moments are entities defined by a customer using a system such as system100 of FIG. 1. A moment may be defined by a regular expression matchingthe content of a sent message, or by a unique identifier. In a typicalconfiguration, the chatbot agent is configured to specify a particularmoment by use of an identifier when it makes a fetch request, and passesthe moment identifier to the SDK interface, which then passes theidentifier to the advertisement server.

RCS message 502 is structured to include a carousel data type includinga plurality of rich cards and associated actions, with a specifiedmoment of “ORDER_COMPLETE.” When the chatbot agent initiates a fetchrequest, it can call an extendedFetch, and include the message ready tosend to the end user via the messaging gateway, such as in the followingfetch request example code:

Moment:“moment-name”

Targeting: [. . . ]

Subscriber: “subscriber-id”

Carousel: [firstItem, secondItem, thirdItem]

When a carousel data type is delivered, as in the embodiment of FIG. 5,the advertisement server may be configured to take the original message(e.g., RCS message 502) and use all existing fetch functionality todetermine whether a smart messaging component can be selected for themoment. Such functionality includes the server selecting a component Cxin a step 504. Selecting a component may include inspecting the carouselto determine if it has a matching rule which may be predetermined forthe data type. If a match is found, a custom card (e.g., component Cx)is selected. The server may also determine an index x at which to insertcomponent Cx in a step 506, and insert component Cx into RCS message 502at index x in a step 508 to modify the makeup of the original carouselof RCS message 502 such that the selected card is inserted into themessage. Any associated actions are redirected through tracking serverto measure engagement with the newly added card. Such steps combinedperformed on RCS message 502 results in a modified RCS message 510including the additional component Cx and associated action Ax. ModifiedRCS message 510 may be returned to the chatbot agent as in the followingreturn example code:

Carousel: [firstItem, secondItem, smartComponent, thirdItem]

The above may be optimized in cases where the SDK has been installed onthe chatbot application. In this case, the chatbot agent need only sendthe typical fetch request, and the client side code can handle theinsertion of the smart messaging component. This can be done without thechatbot application knowing whether it is done client-side or serverside.

In order to control the conversation flow, the present invention definesseveral “template” conversations that have a well-defined shape. Apublisher can allow certain templates and define keywords that are usedto return to the original conversation. Such templates may include, butare not limited to, adding a rich card to an existing carousel, addingan action to an existing message, defining a matching rule thatdetermines when insertion should occur, defining one or more custom richcards, and defining a set of rules that determine selection criteria forthe cards.

In some embodiments, to avoid sending every message to an externalserver, as it may be prohibitively expensive in terms of time orcomputing power, a subset or compressed version of the rules databasemay be transferred to the hook code during initialization or at anysubsequent time. This allows the hook to prescreen messages, and if amessage is deemed to not be a match based on configured rules, the stepof sending it to the advertisement server can be skipped.

FIG. 6 is a flow chart illustrating a method 600 performed by a fetchproxy for shortening uniform resource locators (URLs) for chained clicktracking. Every action that is delivered as part of a component may beassociated with an external web URL or other clickable entity. Whenrendering a component, a customer-specified URL may be wrapped in afetch proxy-specific URL. Therefore, when the subscriber invokes theaction, the fetch proxy in conjunction with the advertisement server(such request proxy 106 and advertisement server 102 described withreference to FIG. 1) receives the request, records information about it,and then uses an HTTP redirect to redirect the subscriber's user agentto the originally-specified target.

Method 600 provides for generation of short URLs for anysubscriber-visible URLs delivered as part of components. For example, ahyperlink to a web pages may be specified by the customer as“https://www.example.com/acme/123”, but may be rewritten as somethinglike “https://drqt.io/1234” when served to the subscriber. Another useof method 600 is to provide custom URL shortening services to acustomer. This allows a customer to use their own custom domains inshort URLs that are visible to the subscriber, and also provides anotherlayer of integration with third party analytics (“click tracking”)providers. So instead of the subscriber seeing “https://drqt.io/1234”,they can instead see “https://myco.com”. Such functionality contributesto branding and security by showing a subscriber trusted domain, andprovides redirection of all clicks through custom domain for externaltracking/analytics.

Method 600 may begin with a chatbot agent retrieving or otherwiseidentifying a moment from a message in a step 602. Step 602 may includesending a fetch request to a fetch proxy, such as request proxy 106described with respect to FIG. 1. In response to receiving a moment froma chatbot agent, the fetch proxy may continue method 600 by proceedingto perform a step 604, in which the fetch proxy determines whether acustom domain is needed for a short URL. If the fetch proxy determinesno in step 604, method 600 may continue to a step 606. Otherwise, if thefetch proxy determines yes in step 604, method 600 continues to a step610.

Step 606 includes initiating a fetch request by the fetch proxy usingnon-custom URL shortening, and sending the fetch request to the API/SDKof the advertisement server. Upon completing transmission of the fetchrequest, method 600 may continue with a step 608, in which theadvertisement server returns a payload (e.g., component and action)embedded with the shortened URL link, such that when the subscriber tapsthe component, the web browser in which the chatbot agent is operatingwill be redirected accordingly. Method 600 may end with step 608, andmay repeat at a time when the chatbot agent identifies another moment.

Step 610 includes initiating a fetch request by the fetch proxy with URLshortening, and sending the fetch request to the API of theadvertisement server. Upon completing transmission of the fetch request,method 600 may continue with a step 612, in which the advertisementserver may optionally modify a configured target URL with dynamic orsubscriber-sensitive data. Such modification in step 612 may includeinserting substitution strings or modifying other parameters, which maybe configured in a web console (such as web console 108 described withreference to FIG. 1).

Method 600 may continue with a step 614, in which the advertisementserver creates a vanity domain URL using a subscriber-specific domainstring. Such a string may be specified in advance by the subscriber(e.g., customer) using the web console to define the domain name. SuchURL generation may follow conventional or known methods of generatingcustomer-specific domain names using strings. Method 600 may continuewith a step 616, which includes replacing the long URL with theshortened URL in the payload (e.g., the message). Step 616 may includethe advertisement server delivering the payload to the chatbot agent,complete with the shortened URL and component matching the rulesdetermined by the advertisement server. Method 600 may end with step616, and may repeat at a time when the chatbot agent identifies anothermoment.

FIG. 7 is a flow chart illustrating a method 700 for click tracking asperformed by a fetch proxy and advertisement server, such as requestproxy 106 and advertisement server 102 described with respect to FIG. 1,according to an embodiment. Method 700 may occur in conjunction withmethod 600 described with reference to FIG. 6. Method 700 operates thesame regardless of whether custom URL shortening occurs in method 600.Generally, method 700 includes receiving a payload request which isanswered by the advertisement server, which inserts a component completewith an action-URL which, when selected by a user, sends a web requestto, in the case of a custom URL, a custom endpoint, which redirects to asystem-specific URL hosted by the advertisement server. Theadvertisement server may record information from the web request in adatabase, such as storage 104 described with reference to FIG. 1, andthen redirect the user to a customer URL around which thesystem-specific was wrapped in method 600.

Method 700 may begin in a manner substantially similar to method 600with a step 702 in which the advertisement server receives a payloadrequest either directly from a chatbot agent or from a fetch proxy. Step702 may occur when a chatbot agent detects a moment in a conversationwith a subscriber, which may prompt the chatbot agent to send a partialfetch request to the fetch proxy or a full fetch request directly to theadvertisement server. After receiving the fetch request in step 702,method 700 may continue with a step 704, in which the advertisementserver selects a component containing an action-URL as a payload forinsertion into a chatbot message in response to the fetch request. Theaction-URL may include an original customer URL for the user to accesswhen selecting the component tied to the action-URL.

Method 700 may continue with a step 706, in which the advertisementserver performs parameter substitution on all action-URLs in a componentto customize the action-URLs to the subscriber- or customer-specificconfigurations set by the customer in a web console (such as web console108 described with reference to FIG. 1). In step 706, the advertisementserver may customize the strings included in the action-URLs to includeinformation such as a server identifier, customer identifier, componentidentifier, or other information used to identify the origin anddestination of the URL.

Method 700 may continue with a step 708, in which the advertisementserver wraps the action-URL in a click-wrapper, such that the action ofclicking on the component redirects a web browser of the user to the URLcontained in the click-wrapper, which is hosted by the advertisementserver. Step 708 may be followed by a step 710, in which theadvertisement server may generate the custom URL for the component bywriting an entry in a database. Such an entry may include the action-URLassociated with the custom shortened URL generated, thereby enabling theadvertisement server to redirect the user to the custom shortened URLwhen the user accesses the server-hosted action-URL.

Method 700 may continue with a step 712, in which the advertisementserver delivers a payload including the click-wrapped and shortened URLsto the chatbot agent from which the fetch request was received. Step 712may further include displaying the payload as a selectable componentwithin the present chatbot conversation being hosted by the agent. Step712 may also include the chatbot agent monitoring the chatbotconversation for an interaction of the user with the componentdisplayed. When such an interaction occurs, method 700 proceeds to astep 714, in which the request to access the shortened URL (e.g., thecustom endpoint) is redirected to the advertisement server. Whenredirected to the advertisement server first, the advertisement serverperforms a step 716 including recording the click in the databaseassociated with the shortened URL of the component, the database recordincluding a subscriber identifier, fetch identifier, or the like toidentify the data record. The click-tracking portion of method 700terminates with step 716.

Method 700 may continue with a step 718, in which, after recording theclick in the database in step 716, advertisement server sets a cookie inan HTTP redirect response, and follows step 718 with a step 720 in whichthe advertisement server redirects the user to the original action-URLencoded in the click-wrapper. During steps 716 through 720, the user isredirected twice but reaches only a single end destination, that of theoriginal action-URL, with the original action-URL now containing thecookie added in step 718.

Method 700 may continue will a step 722, in which, when the customer isredirected to the original customer URL configured in the action-URL,the user device accessing the original URL may store the cookie in alocal datastore. The user device may be similar to mobile terminal 122described with reference to FIG. 1. After storing the cookie, method 700may continue to a step 724 in which the user device will render theoriginal URL to the user, such that the user may interact with thecontent included there. Method 700 may terminate with step 724, and mayrepeat at a time when the advertisement server has received anotherpayload request.

In some embodiments, the chatbot agent may pre-fetch the URL. In such aninstance, the URL may not be selected by the user, and the advertisementserver will detect such a redirect as a non-user-initiated request. Theadvertisement server will not record such a redirect as a click, butwill still redirect the request to the originally configured URL, whichmay include bot-specific content for display to the user.

FIG. 8 is a flow chart illustrating an example of a method 800 forconversion tracking of components, according to an embodiment. Aconversion is a record that a subscriber performed some activity thatwas the desired outcome of sending them a component. Typically, aconversion is associated with performing some action on a web page,though it may be an action performed in another manner, such ascompleting a phone call or purchasing a product in a physical store.Method 800 may be performed by an advertisement server, such asadvertisement server 102 described with reference to FIG. 1.

Method 800 may occur in response to a subscriber clicking on an actionin a component, after which the subscriber is redirected through theadvertisement server as described with reference to FIG. 7. As part ofthe click tracking, the subscriber's user agent is provided with an HTTPcookie (“click-tracking cookie”) that records a unique identifier(“fetch-id”) associated with the original Fetch Request that generatedthe Component. Because this fetch-id is stored in a database accessibleto the advertisement server, and associated with the fetch request,having the fetch-id gives the advertisement server enough information toknow which subscriber, moment, rule, and component are associated withit.

Method 800 may begin with a step 802 in the advertisement serverreceives a request for a conversion tracking pixel in order for thecustomer to know if a particular action of value has been taken by asubscriber (e.g., a “conversion” has occurred). The conversion trackingpixel is an HTML element that, when rendered by a subscriber's webbrowser, results in an HTTP request being made to the advertisementserver. A conversion tracking pixel looks like:

<image height=“1” width=1″ style=“display:none”

src=“https://api..io/event?key=<apikey>&name=<conversion-type>”>

The customer can cause this pixel to be displayed to a subscriber byplacing it on a web page, html email, or other HTML interface. Thispixel or script generates a web request to the advertisement serverwhenever a web visitor sees the page on which it is integrated. If theweb visitor is a subscriber who had previously clicked on an actionprovided by the advertisement server, and therefore gone through theclick-tracking process described above, their user agent will providethe HTTP cookie generated earlier as part of the fetch request.

Method 800 may continue with a step 804, in which the advertisementserver determines whether a click-tracking cookie is found in therequest for the tracking pixel. If, in step 804, the advertisementserver determines that the click-tracking cookie is not found in therequest, no conversion is deemed to have taken place, and method 800 mayend without the advertisement server taking further action.

If, in step 804, a click-tracking cookie is found, method 800 mayproceed to a step 806 in which the advertisement server determines if anetwork-id property of the click-tracking cookie matches the network-idassociated with the API key specified in the conversion tracking pixel.If the advertisement server determines no in step 806, method 800 mayend without the advertisement server taking further action. If theadvertisement server determines yes in step 806, method 800 may proceedto a step 808.

In step 808, a conversion is deemed to have occurred. In this situation,the fetch-id property is extracted from the click-tracking cookie by theadvertisement server. Method 800 may proceed to a step 810, in which thefetch-id property is used to determine the subscriber, moment, rule, andconversion associated with the original fetch request. This informationis used to write a conversion event to a database such as historicaldatabase 104 c described with reference to FIG. 1, and update countersthat are visible to the customer in reports and journals. Method 800 mayend with step 810, and may repeat at a time when the advertisementserver receives another request for a tracking pixel.

FIG. 9 is a flow chart illustrating a method 900 for interactiontracking of augmented message streams, according to an embodiment. Inaddition to tracking subscriber clicks on actions that represent web(HTTP) targets, the advertisement server can track other interactionsbetween a subscriber and a message component. For example, in somecomponents, an action may cause the subscriber's user agent to start atelephone call, or to open a local application on their device. Becausethese actions do not always involve making web requests, it is notpossible to use traditional click-tracking mechanisms that rely on usingintermediate HTTP servers to record clicks, and redirect to the target.The customer is therefore unable to use traditional click-tracking tounderstand whether and/or how much subscribers are interacting withmessage elements when non-HTTP Action targets are used.

In order to give customers visibility into which actions are interactedwith by a subscriber, and which conversions occur after the subscriberhas interacted with messaging components via actions that do notgenerate web requests, the advertisement server supports interactiontracking, by execution of method 900. Interaction tracking recordsevents for subscriber actions taken in rich messaging clientapplications, such as tapping on “click-to-call”,“click-to-open-application”, or the like.

Some gateways provide agents with a mechanism by which the agent may benotified when the subscriber has read a message. The advertisementserver, via hooks in the SDK, can process these read receipts and recordthem as subscriber interactions. By associating read receipts withspecific fetch requests, customers gain more insight into howsubscribers are interacting with ads. In alternative embodiments, somegateways work with the software on the subscriber's device to provide amechanism by which a chatbot agent may receive a callback when asubscriber interacts with a message element. For example, when an enduser taps on a chip provided as part of a message, the gateway will sendthe agent that originated the chip a notification message. Thenotification message may include custom postback data that was providedby the chatbot agent when the message/chip was originally sent. Method900 may begin with a step 902, in which the advertisement serverreceives a read receipt or a callback notification from a chatbotmessage including content generated by a fetch request.

Method 900 may continue with a step 904, in which the advertisementserver extracts postback data including a server identifier and a fetchrequest identifier. When the advertisement server renders actions into agateway-specific format, it associates with each rendered actionpostback data that is a string beginning with a specific prefix, suchas, “@-”. During step 904, the SDK utilizes a handler to receive allnotification messages generated by the gateway (i.e., whether they areassociated with messages created by the advertisement server or not) andinspect the postback data associated with the notification, looking forthe specific prefix.

In a step 906 of method 900, the handler determines whether the serveridentifier matches that of the advertisement server, effectivelyrecognizing when an action generated by the advertisement server hasbeen taken by the subscriber. This is achieved by the handlerdetermining the server identifier includes the specified prefix, therebydetermining “yes” in step 906. This allows such actions to bedistinguished from postback events generated by the chatbot applicationitself. The messaging gateway will communicate to the chatbot agent thatthe user has taken a suggested action by sending postback data that wasoriginally associated with the action. Every time such postback data issent to the chatbot agent, it passes it through a function of the SDKdetermining if the data is associated with an action generated by theadvertisement server, check_postback_data( ) If the handler determinesno in step 906, method 900 may terminate without further action onbehalf of the handler, chatbot agent, or advertisement server.

Upon determining “yes” in step 906, method 900 may continue with a step908. In addition to the prefix, the custom postback data includes otherinformation, including the fetch-id associated with the original fetchrequest that generated the component. As part of step 908, the SDK mayextract this information and send it to an endpoint on the advertisementserver handled by the interaction-tracking service that is conceptuallyvery similar to the custom endpoint used for click-tracking. During step908, the advertisement server may confirm that the received fetch-idmatches that of a fetch request data record stored in the historicaldatabase. Upon identifying a matching fetch request data record, method900 may proceed to a step 910.

During step 910, the advertisement server updates the data record of thefetch request with the associated postback data, where it can be trackedand/or trigger additional actions. For example, if the subscriber hadtapped on a “click-to-call” chip that had originally been defined as anaction, the advertisement server can record this event in its logs.Method 900 may further include a step 912, in which the advertisementserver transmits the fetch request data record including the newly addedpostback data to a report server, such as report server 110 describedwith reference to FIG. 1. The report server may make such data recordsavailable via reports and journals. Method 900 may terminate with step912, and may repeat upon receipt of another read receipt or a callbacknotification from a chatbot message.

To provide an illustrative example of the above described embodiments,the following code serves as an example hook utilized by the systems andmethods herein:

const express = require ( ′express′ ); const request = require (′request′ ); const app = express( ).use( require ( ′body-parser′ ).json()); const PAGE_ACCESS_TOKEN = process.env.PAGE_ACCESS_TOKEN ∥″<invalid>″; let VERIFY_TOKEN = process.env.VERIFY_TOKEN ∥″<provide-your-own-secure- token>″ ; const _PLAYGROUND_API_KEY =″5rp26o1WB5IBQ6gVTg″ ; // acceptable for use in testing const _API_KEY =process.env._API_KEY ∥ _PLAYGROUND_API_KEY; const _API_SECRET =process.env._API_SECRET ∥ null; const _API_ROOT = process.env._API_ROOT∥ ″https://api..io″; app.listen(process.env.PORT ∥ 1337 , ( ) => console.log( ′ example webhook is listening′ )); app.get( ′/webhook′ , (req,res) => {  let mode = req.query[ ′hub.mode′ ];  let token = req.query[′hub.verify_token′];  let challenge = req.query[ ′hub.challenge′ ];  if(mode === ′subscribe′ && token === VERIFY_TOKEN) {   console .log(′WEBHOOK_VERIFIED′ );   res.status( 200 ).send(challenge);  } else {  res.sendStatus( 403 );  } }); app.post( ′/webhook′ , (req, res) => { let body = req.body;  if (body.object === ′page′ ) {  body.entry.forEach( function (entry) {    let webhook_event =entry.messaging[ 0 ];    let sender_psid = webhook_event.sender.id;   if (webhook_event.message) {     handleMessage(sender_psid,webhook_event.message);    }   });   res.status( 200 ).send(′EVENT_RECEIVED′);  } else { res.sendStatus( 404 ); } }); functionhandleMessage(sender_psid, received_message) {  let response;  if(!received_message.text) {   return  }  response = {   ″text″ : ′Yousaid: ″ ${received_message.text} ″′  };  callSendAPI(sender_psid,response);  const exampleMoments = [   ″text″, // => ″fbm-text″  ″rich-card″, // => ″fbm-rich-card″   ″media″ // => ″fbm-media″  ];  //e.g., ″Rich card. ″ => ″rich-card″  const m =received_message.text.toLowerCase( ).replace( ∧W/g , ″-″ );  if(exampleMoments.some(moment => moment === m)) {   fetch(sender_psid,″fbm-″ + m);  } } function callSendAPI(sender_psid, response) {  letrequest_body = {   ″recipient″ : {    ″id″ : sender_psid   },  ″message″ : response  };  request({   ″uri″ :″https://graph.facebook.com/v2.6/me/messages″,   ″qs″ : { ″access_token″: PAGE_ACCESS_TOKEN },   ″method″ : ″POST″,   ″json″ : request_body  },(err, res, body) => {   if (!err) {   } else {    console .error(″Facebook send request failed:″ + err)   }  }); } functionfetch(sender_psid, moment) {  let request_body = {   format: ″FBM″ ,  ″moment″ : moment,   ″subscriber″ : sender_psid,   // You may pass anynon-personally-identifiable information you have   // about thesubscriber in the targeting object.   ″targeting″ : ′ {    ″language″:″en″   }′  };  const auth = _API_SECRET && {   ″user″ : _API_KEY,  ″pass″ : _API_SECRET,  };  request({   ″uri″ : _API_ROOT + ″/fetch″,  ″qs″ : {″key″ : _API_KEY },   ″method″ : ″POST″ ,   ″json″ :request_body,   ... {auth},  }, (err, res, body) => {   if (err) {   console .error( ″ fetch for Moment ″′ + moment + ″′ failed: + err);  } else if (res && res.statusCode !== 200 && res.statusCode !== 204 ) {   console .error( ″ fetch for Moment ″′ + moment + ″′ failed: ″     +res.statusCode + ″ ″ + JSON .stringify(res.body));   } else if (body &&body.payload) {    console .log( ″ fetch for Moment ″′ + moment +″′received payload.″ )    callSendAPI(sender_psid, JSON.parse(body.payload));   } else {    console .log( ″ fetch for Moment″′ + moment + ″′ was empty.″ )   }  }); }

Page 42

Page 43

Page 44

FIG. 10 is an example of an implementation of the systems and methodspresented herein. In the example of FIG. 10, the highlighted cards havebeen inserted into the existing weather carousel for the subscriber.

FIG. 11 is another example of an implementation of the systems andmethods presented herein. In the example of FIG. 11, an offer to thesubscriber is inserted into the chatbot exchange as a part of their RCScheck-in notification.

FIG. 12 is yet another example of an implementation of the systems andmethods presented herein. In the example of FIG. 12, the SMS subscriberexperience is enhanced when the subscriber begins to run out of theirmobile data quota.

The foregoing method descriptions and the process flow diagrams areprovided merely as illustrative examples and are not intended to requireor imply that the steps of the various embodiments must be performed inthe order presented. The steps in the foregoing embodiments may beperformed in any order. Words such as “then,” “next,” etc. are notintended to limit the order of the steps; these words are simply used toguide the reader through the description of the methods. Althoughprocess flow diagrams may describe the operations as a sequentialprocess, many of the operations can be performed in parallel orconcurrently. In addition, the order of the operations may bere-arranged. A process may correspond to a method, a function, aprocedure, a subroutine, a subprogram, and the like. When a processcorresponds to a function, the process termination may correspond to areturn of the function to a calling function or a main function.

The various illustrative logical blocks, modules, circuits, andalgorithm steps described in connection with the embodiments disclosedherein may be implemented as electronic hardware, computer software, orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentinvention.

Embodiments implemented in computer software may be implemented insoftware, firmware, middleware, microcode, hardware descriptionlanguages, or any combination thereof. A code segment ormachine-executable instructions may represent a procedure, a function, asubprogram, a program, a routine, a subroutine, a module, a softwarepackage, a class, or any combination of instructions, data structures,or program statements. A code segment may be coupled to another codesegment or a hardware circuit by passing and/or receiving information,data, arguments, parameters, or memory contents. Information, arguments,parameters, data, etc. may be passed, forwarded, or transmitted via anysuitable means including memory sharing, message passing, token passing,network transmission, etc.

The actual software code or specialized control hardware used toimplement these systems and methods is not limiting of the invention.Thus, the operation and behavior of the systems and methods weredescribed without reference to the specific software code beingunderstood that software and control hardware can be designed toimplement the systems and methods based on the description herein.

When implemented in software, the functions may be stored as one or moreinstructions or code on a non-transitory computer-readable orprocessor-readable storage medium. The steps of a method or algorithmdisclosed herein may be embodied in a processor-executable softwaremodule, which may reside on a computer-readable or processor-readablestorage medium. A non-transitory computer-readable or processor-readablemedia includes both computer storage media and tangible storage mediathat facilitate transfer of a computer program from one place toanother. A non-transitory processor-readable storage media may be anyavailable media that may be accessed by a computer. By way of example,and not limitation, such non-transitory processor-readable media maycomprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage,magnetic disk storage or other magnetic storage devices, or any othertangible storage medium that may be used to store desired program codein the form of instructions or data structures and that may be accessedby a computer or processor. Disk and disc, as used herein, includecompact disc (CD), laser disc, optical disc, digital versatile disc(DVD), floppy disk, and Blu-ray disc where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above should also be included within the scope ofcomputer-readable media. Additionally, the operations of a method oralgorithm may reside as one or any combination or set of codes and/orinstructions on a non-transitory processor-readable medium and/orcomputer-readable medium, which may be incorporated into a computerprogram product.

The preceding description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the presentinvention. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the invention. Thus, the present invention is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the following claims and theprinciples and novel features disclosed herein.

While various aspects and embodiments have been disclosed, other aspectsand embodiments are contemplated. The various aspects and embodimentsdisclosed are for purposes of illustration and are not intended to belimiting, with the true scope and spirit being indicated by thefollowing claims.

What is claimed is:
 1. A method for inserting interactive payloads intomessages, the method comprising: receiving, by one or more processors, arequest for augmentation of a message, the message having a plurality ofindexed components; identifying, by the one or more processors, a rulecorresponding to a moment derived from an interaction with the message;selecting, by the one or more processors, based on targeting parametersfor the moment, a component associated with the identified rule;identifying, by the one or more processors, an index in the message atwhich to insert the component; modifying, by the one or more processors,the plurality of indexed components of the message to include thecomponent at the index; and transmitting, by the one or more processors,in response to the received request, the modified message, the modifiedmessage including the component.
 2. The method of claim 1, furthercomprising: identifying, by the one or more processors from the request,the moment derived from the interaction with the message, userattributes of a user associated with the interaction, and anidentification of a format of a communication type associated with themessage; and modifying, by the one or more processors, the modifiedmessage based on the identification of the format of the communicationtype of the message.
 3. The method of claim 1, wherein the request is afirst request and further comprising: transmitting, by the one or moreprocessors, a second request for user attributes of a user associatedwith the first request; and receiving, by the one or more processors, inresponse to the transmitted second request, the user attributesassociated with the first request.
 4. The method of claim 3, furthercomprising retrieving, by the one or more processors, the userattributes from a memory element.
 5. The method of claim 1, whereinmodifying the plurality of indexed components comprises: identifying, bythe one or more processors, a user action for the component; andmodifying, by the one or more processors, the plurality of indexedcomponents of the message to include the component and the user actionat the index.
 6. The method of claim 1, further comprising loading, bythe one or more processors, the rule from a database.
 7. The method ofclaim 3, wherein identifying the rule comprises determining, by the oneor more processors, based on the user attributes, the rule associatedwith the moment.
 8. The method of claim 1, wherein selecting thecomponent comprises: loading, by the one or more processors, data from acache memory; and selecting, by the one or more processors based on theloaded data, the component associated with the rule.
 9. The method ofclaim 1, wherein transmitting the message comprises transmitting, by theone or more processors, the message including the component and aspecification of a format of the component.
 10. The method of claim 1,further comprising determining, by the one or more processors, anidentifier for a media file to be included in the message.
 11. Themethod of claim 10, further comprising creating, by the one or moreprocessors, an alternate identifier for the media file to be included inthe message.
 12. The method of claim 11, wherein transmitting themessage comprises transmitting, by the one or more processors, themessage, the message including the component and the alternateidentifier for the media file to be included in the message.
 13. Themethod of claim 10, wherein transmitting the message comprisestransmitting, by the one or more processors, the message, the messageincluding the component and the identifier for the media file to beincluded in the message.
 14. The method of claim 5 wherein transmittingthe message comprises transmitting, by the one or more processors, themessage including the component and the user action for the component.15. A system for inserting interactive payloads into messages, thesystem comprising: one or more processors coupled to memory, the one ormore processors configured to: receive a request for augmentation of amessage, the message having a plurality of indexed components; identifya rule corresponding to a moment derived from an interaction with themessage; select, based on targeting parameters for the moment, acomponent associated with the identified rule; identify an index in themessage at which to insert the component; modify the plurality ofindexed components of the message to include the component at the index;and transmit, in response to the received request, the modified message,the modified message including the component.
 16. The system of claim15, wherein the one or more processors are further configured to;identify from the request, the moment derived from the interaction withthe message, user attributes of a user associated with the interaction,and an identification of a format of a communication type associatedwith the message; and modify the modified message based on theidentification of the format of the communication type of the message.17. The system of claim 15, wherein the request is a first request andwherein the one or more processors are further configured to: transmit asecond request for user attributes of a user associated with the firstrequest; and receive, in response to the transmitted second request, theuser attributes associated with the first request.
 18. The system ofclaim 17, wherein the one or more processors are further configured toretrieve the user attributes from a memory element.
 19. The system ofclaim 15, wherein the one or more processors are further configured to:identify a user action for the component; and modify the plurality ofindexed components of the message to include the component and the useraction at the index.
 20. The system of claim 15, wherein the one or moreprocessors are further configured to transmit a specification of aformat of the component.